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Abstract 
This document provides a framework to allow the development of 
protocol extensions to support Generalized Multi-Protocol Label 
Switching (GMPLS) and Path Computation Element (PCE) control of 
Optical Transport Networks (OTNs) as specified in ITU-T 
Recommendation G.709 as published in 2012. 
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Les 


Introduction 


Optical Transport Networks (OTNs) have become a mainstream layer 1 
technology for the transport network. Operators want to introduce 
control-plane capabilities based on GMPLS to OTN to realize the 
benefits associated with a high-function control plane (e.g., 
improved network resiliency, resource usage efficiency, etc.). 


GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time 
Division Multiplexing (TDM) networks (e.g., Synchronous Optical 
NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous 
Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching 
optical networks, and spatial switching (e.g., incoming port or fiber 
to outgoing port or fiber). The GMPLS architecture is provided in 
[RFC3945], signaling function and Resource Reservation Protocol - 
Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] 
and [RFC3473], routing and Open Shortest Path First (OSPF) extensions 
are described in [RFC4202] and [RFC4203], and the Link Management 
Protocol (LMP) is described in [RFC4204]. 


The GMPLS signaling extensions defined in [RFC4328] provide the 
mechanisms for basic GMPLS control of OTN based on the 2001 revision 
of the G.709 specification. The 2012 revision of the G.709 
Specification, [G709-2012], includes new features, for example, 
various multiplexing structures, two types of Tributary Slots (TSs) 
(i.e., 1.25 Gbps and 2.5G bps), and extension of the Optical channel 
Data Unit-j (ODUj) definition to include the ODUflex function. 


This document reviews relevant aspects of OTN technology evolution 
that affect the GMPLS control-plane protocols and examines why and 
how to update the mechanisms described in [RFC4328]. This document 
additionally provides a framework for GMPLS control of OTN and 
includes a discussion of the implications for the use of the PCE 
[RFC4655]. 


For the purposes of the control plane, the OTN can be considered to 
be comprised of ODU and wavelength (Optical Channel (OCh)) layers. 
This document focuses on the control of the ODU layer, with control 
of the wavelength layer considered out of the scope. Please refer to 
[RFC6163] for further information about the wavelength layer. 


Terminology 
OTN: Optical Transport Network 
OPU: Optical Channel Payload Unit 


ODU: Optical Channel Data Unit 
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OTU: Optical Channel Transport Unit 
OMS: Optical Multiplex Section 

MSI: Multiplex Structure Identifier 
TPN: Tributary Port Number 


LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1,2, 2e, 3, 4, or 
flex) represents the container transporting a client of the OTN that 

is either directly mapped into an OTUk (k = j) or multiplexed into a 

server HO ODUk (k > j) container. 


HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) 
represents the entity transporting a multiplex of LO ODUJ tributary 
signals in its OPUk area. 


ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 
bit rate tolerance of +/-100 ppm (parts per million). 


In general, throughout this document, "ODUj" is used to refer to ODU 
entities acting as an LO ODU, and "ODUk" is used to refer to ODU 
entities being used as an HO ODU. 


3. G.709 Optical Transport Network 


This section provides an informative overview of the aspects of the 
OTN impacting control-plane protocols. This overview is based on the 
ITU-T Recommendations that contain the normative definition of the 
OTN. Technical details regarding OTN architecture and interfaces are 
provided in the relevant ITU-T Recommendations. 


Specifically, [G872-2012] describes the functional architecture of 
optical transport networks providing optical signal transmission, 
multiplexing, routing, supervision, performance assessment, and 
network survivability. The legacy OTN referenced by [RFC4328] 
defines the interfaces of the optical transport network to be used 
within and between subnetworks of the optical network. With the 
evolution and deployment of OTN technology, many new features have 
been specified in ITU-T recommendations, including, for example, new 
ODUO, ODU2e, ODU4, and ODUflex containers as described in 
[G709-2012]. 
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3.1. OTN Layer Network 


The simplified signal hierarchy of OTN is shown in Figure 1, which 
illustrates the layers that are of interest to the control plane. 
Other layers below OCh (e.g., Optical Transmission Section (OTS)) are 
not included in this figure. The full signal hierarchy is provided 
in [G709-2012]. 


Client signal 


ODUj 
OTU/OCh 
OMS 


Figure 1: Basic OTN Signal Hierarchy 


Client signals are mapped into ODUj containers. These ODUj 
containers are multiplexed onto the OTU/OCh. The individual OTU/OCh 
signals are combined in the OMS using Wavelength Division 
Multiplexing (WDM), and this aggregated signal provides the link 
between the nodes. 
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3.1.1. Client Signal Mapping 


The client signals are mapped into an LO ODUj. The current values of 
j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. The 
approximate bit rates of these signals are defined in [G709-2012] and 
are reproduced in Tables 1 and 2. 


4----------------------- 4----------------------------------- + 
| ODU Type | ODU nominal bit rate 
+----------------------- 4----------------------------------- t 
| ODUO | 1,244,160 Kbps | 
| ODU1 | 239/238 x 2,488,320 Kbps | 
| ODU2 | 239/237 x 9,953,280 Kbps | 
| ODU3 | 239/236 x 39,813,120 Kbps | 
| ODU4 | 239/227 x 99,532,800 Kbps | 
| ODU2e | 239/237 x 10,312,500 Kbps | 
| ODUflex for | | 
[Constant Bit Rate (CBR)| 239/238 x client signal bit rate | 
| Client signals | | 
ODUflex for Generic | 
| Framing Procedure Configured bit rate 
| - Framed (GFP-F) | | 
| Mapped client signal | | 
+----------------------- 4----------------------------------- + 


Table 1: ODU Types and Bit Rates 
NOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps 


(ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 
104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e6). 
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4---------------2-------- 4-------------2-2-2-2--2-2----2---2-------- + 
| ODU Type | ODU bit rate tolerance | 
4------------2----2------- 4---------------2-2-2--2-2----2-2--2-2------- + 
| ODUO | */-20 ppm | 
| ODU1 | +/-20 ppm | 
| ODU2 | +/-20 ppm | 
| ODU3 | +/=20 ppm | 
| ODU4 | +/-20 ppm | 
ODU2e +/-100 ppm 
| | ODUflex for CBR | | 
| Client signals | +/-100 ppm 
| ODUflex for GFP-F | | 
| Mapped client signal | +/-100 ppm 
4-------------2--2-2------- 4---------------2-2----2----2-2--2-2------- + 


Table 2: ODU Types and Tolerance 


One of two options is for mapping client signals into ODUflex 
depending on the client signal type: 


- Circuit clients are proportionally wrapped. Thus, the bit rate is 
defined by the client signal, and the tolerance is fixed to +/-100 


ppm. 


- Packet clients are mapped using the Generic Framing Procedure 
(GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an 
integral number of tributary slots of the smallest HO ODUk path 
over which the ODUflex(GFP) may be carried, and the tolerance 
should be +/-100 ppm. 


Note that additional information on G.709 client mapping can be found 
in [G7041]. 


3.1.2. Multiplexing ODUj onto Links 


The links between the switching nodes are provided by one or more 
wavelengths. Each wavelength carries one OCh, which carries one OTU, 
which carries one ODU. Since all of these signals have a 1:1:1 
relationship, we only refer to the OTU for clarity. The ODUjs are 
mapped into the TSs (Tributary Slots) of the OPUk. Note that in the 
case where j-k, the ODUj is mapped into the OTU/OCh without 
multiplexing. 
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The initial versions of G.709 referenced by [RFC4328] only provided a 
single TS granularity, nominally 2.5 Gbps. [G709-2012] added an 
additional TS granularity, nominally 1.25 Gbps. The number and type 
of TS provided by each of the currently identified OTUk are provided 


below: 
Tributary Slot Granularity 
2.5 Gbps 1.25 Gbps Nominal Bit Rate 
OTU1 t 2 2.5 Gbps 
OTU2 4 8 10 Gbps 
OTU3 16 32 40 Gbps 
OTUA =s 80 100 Gbps 


To maintain backward compatibility while providing the ability to 
interconnect nodes that support a 1.25 Gbps TS at one end of a link 
and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment 
to fall back to the use of a 2.5 Gbps TS when connected to legacy 
equipment. This information is carried in band by the payload type. 


The actual bit rate of the TS in an OTUk depends on the value of k. 
Thus, the number of TSs occupied by an ODUj may vary depending on the 
values of j and k. For example, an ODU2e uses 9 TSs in an OTU3 but 
only 8 in an OTU4. Examples of the number of TSs used for various 
cases are provided below (referring to Tables 7-9 of [G709-2012]): 


- ODUO into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS 
granularity 
o ODUO occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2, 
ODU3, or ODU4 


- ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS 
granularity 
o ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4 


- ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity 
o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3 


- ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity 
o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4 


- ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity 
o ODU2 occupies 4 of the 16 TSs for ODU3 


- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity 
o ODU3 occupies 31 of the 80 TSs for ODU4 
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In 


ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS 

granularity 

o ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or 
ODUA (n <= Total TS number of ODUk) 


ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity 
o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for 
ODUA 


general, the mapping of an ODUJ (including ODUflex) into a 


specific OTUk TS is determined locally, and it can also be explicitly 
controlled by a specific entity (e.g., head end or Network Management 
System (NMS)) through Explicit Label Control [RFC3473]. 


32 


ly Structure of MSI Information 


When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the 
information that has to be transported in-band in order to allow for 
correct demultiplexing. This information, known as MSI, is 

transported in the OPUk overhead and is local to each link. In case 


of 
be 


bidirectional paths, the association between the TPN and TS must 
the same in both directions. 


The MSI information is organized as a set of entries, with one entry 
for each HO ODUj TS. The information carried by each entry is: 


Payload Type: the type of the transported payload. 


TPN: the port number of the ODUJ transported by the HO ODUk. The 
TPN is the same for all the TSs assigned to the transport of the 
same ODUj instance. 


For example, an ODU2 carried by an HO ODU3 is described by 4 entries 


in 


the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8 


entries when the TS granularity is 1.25 Gbps. 


On 


each node and on every link, two MSI values have to be provisioned 


(referring to [G798]): 


Zhang, 


The Transmitted MSI (TxMSI) information inserted in OPU (e.g., 
OPU3) overhead by the source of the HO ODUk trail. 


The Expected MSI (ExMSI) information that is used to check the 


Accepted MSI (AcMSI) information. The AcMSI information is the 
MSI valued received in-band, after a three-frame integration. 
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As described in [G798], the sink of the HO ODU trail checks the 
complete content of the AcMSI information against the ExMSI. If the 
AcMSI is different from the ExMSI, then the traffic is dropped, and a 
payload mismatch alarm is generated. 


Provisioning of TPN can be performed by either a network management 


system or control plane. In the last case, the control plane is also 
responsible for negotiating the provisioned values on a link-by-link 
basis. 

4. Connection Management in OTN 


OTN-based connection management is concerned with controlling the 
connectivity of ODU paths and OCh. This document focuses on the 
connection management of ODU paths. The management of OCh paths is 
described in [RFC6163]. 


While [G872-2001] considered the ODU to be a set of layers in the 
same way as SDH has been modeled, recent ITU-T OTN architecture 
progress [G872-2012] includes an agreement to model the ODU as a 
single-layer network with the bit rate as a parameter of links and 
connections. This allows the links and nodes to be viewed in a 
single topology as a common set of resources that are available to 
provide ODUj connections independent of the value of j. Note that 
when the bit rate of ODUj is less than the server bit rate, ODUj 
connections are supported by HO ODU (which has a one-to-one 
relationship with the OTU). 


From an ITU-T perspective, the ODU connection topology is represented 
by that of the OTU link layer, which has the same topology as that of 
the OCh layer (independent of whether the OTU supports an HO ODU, 
where multiplexing is utilized, or an LO ODU in the case of direct 
mapping). 


Thus, the OTU and OCh layers should be visible in a single 
topological representation of the network, and from a logical 
perspective, the OTU and OCh may be considered as the same logical, 
switchable entity. 


Note that the OTU link-layer topology may be provided via various 
infrastructure alternatives, including point-to-point optical 
connections, optical connections fully in the optical domain, and 
optical connections involving hybrid sub-lambda/lambda nodes 
involving 3R, etc. See [RFC6163] for additional information. 
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4.1. Connection Management of the ODU 


An LO ODUj can be either mapped into the OTUk signal (j = k) or 
multiplexed with other LO ODUjs into an OTUk (j « k), and the OTUk is 
mapped into an OCh. 


From the perspective of the control plane, there are two kinds of 
network topology to be considered. 


(1) ODU layer 


In this case, the ODU links are presented between adjacent OTN nodes, 
as illustrated in Figure 2. In this layer, there are ODU links with 
a variety of TSs available, and nodes that are Optical Digital Cross 
Connects (ODXCs). LO ODU connections can be set up based on the 
network topology. 


Link #5 +--+---+--+ Link #4 
4-------------------------- | | -------------------------- + 
| | opxc | | 
| +--------- + | 

Node E 
+-++---+--+ 4+--+---+--4+ 4+--+---+--4+ +--+---+-+4+ 
| |Link #1 | Ee #2 | E 83 | 
|-------- MEME 
| ODXC | | opxc | | opxc | | opxc | 
4R--------- * 4R--------- + 4R--------- * 4R--------- + 
Node A Node B Node C Node D 


Figure 2: Example Topology for LO ODU Connection Management 


If an ODUj connection is requested between Node C and Node E, 
routing/path computation must select a path that has the required 
number of TSs available and that offers the lowest cost. Signaling 
is then invoked to set up the path and to provide the information 
(e.g., selected TSs) required by each transit node to allow the 
configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j 
< k) and demapping (j = k) or demultiplexing (j < k). 


(2) ODU layer with OCh switching capability 


In this case, the OTN nodes interconnect with wavelength switched 
nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or 
Optical Cross-Connect (OXC)) that are capable of OCh switching; this 
is illustrated in Figures 3 and 4. There are the ODU layer and the 
OCh layer, so it is simply a Multi-Layer Network (MLN) (see 
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[RFC6001]). OCh connection 
described in Section 5.1. 


In this case, 
layer to be visible to the 
which case the topology wou 
however, a cloud representi 
represented. In Figure 3, 
OCh-layer network topology. 


Link #5 
T e —— MÀS —Ó— ÁÓ— — OR — — 
| 
| 
+-+----- + +------ | | 
| | \ 
| |Link #1 | 
| 4-------- + 
| opxc_ | | ODXC 
4+------- + +--------- 
Node A Node B 
Figure 3: OCh Hidden Top 
Link #5 
+ SSS SoS ee ee ee Se ee 
| — 
| +-++ 
| Node £ | | 
| +-++ 
| | 
+-+----- + +----+---- 
| |Link #1 | 
| 4-------- + 
| opxc | | ODXC 
+------- + +--------- 
Node A Node B 
Figure 4: OCh Visible Top 
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s may be created on demand, which is 


an operator may choose to allow the underlying OCh 


ODU routing/path computation process, in 
ld be as shown in Figure 4. In Figure 3, 
ng OCh-capable switching nodes is 

the operator choice is to hide the real 


Node E 
peers * Link #4 
| a ce i 
/ B | 
OCh domain 
|| ------ + 4----- +-+ 
\ // | | 
-------- |Link #3 | | 
| | 4-------- + + 
4-------- + ODbXC | | opxc | 
+Link #2 +--------- + T------- t 
Node C Node D 


ology for LO ODU Connection Management 


4R--------- + Link #4 
| |----------------------- : 
| ODXC |----+ | 
4+--------- + +++ | 
Node E | | Node g 
++-+ | 
i | | 
+--| --—---- +--+ 4----- +-+ 
| +--+ | |Link #3 | | 
| Node h | +-------- + 
4-------- * ODXC | | "GBXG- | 
+ Link $24--------- * 4------- * 
Node C Node D 


ology for LO ODUj Connection Management 
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In Figure 4, the cloud in the previous figure is substituted by the 
real topology. The nodes f, g, and h are nodes with OCh switching 
capability. 


In the examples (i.e., Figures 3 and 4), we have considered the case 
in which LO ODUj connections are supported by an OCh connection and 
the case in which the supporting underlying connection can also be 
made by a combination of HO ODU/OCh connections. 


In this case, the ODU routing/path selection process will request an 
HO ODU/OCh connection between node C and node E from the OCh domain. 
The connection will appear at the ODU level as a Forwarding 
Adjacency, which will be used to create the ODU connection. 


I 


5.  GMPLS/PCE Implications 


The purpose of this section is to provide a set of requirements to be 
evaluated for extensions of the current GMPLS protocol suite and the 
PCE applications and protocols to encompass OTN enhancements and 
connection management. 


5.1. Implications for Label Switched Path (LSP) Hierarchy 


The path computation for an ODU connection request is based on the 
topology of the ODU layer. 


The OTN path computation can be divided into two layers. One layer 
is OCh/OTUk; the other is ODUj. [RFC4206] and [RFC6107] define the 
mechanisms to accomplish creating the hierarchy of LSPs. The LSP 
management of multiple layers in OTN can follow the procedures 
defined in [RFC4206], [RFC6001], and [RFC6107]. 


As discussed in Section 4, the route path computation for OCh is in 
the scope of the Wavelength Switched Optical Network (WSON) 

[RFC6163]. Therefore, this document only considers the ODU layer for 
an ODU connection request. 


The LSP hierarchy can also be applied within the ODU layers. One of 
the typical scenarios for ODU layer hierarchy is to maintain 
compatibility with introducing new [G709-2012] services (e.g., ODUO 
and ODUflex) into a legacy network configuration (i.e., the legacy 
OTN referenced by [RFC4328]). In this scenario, it may be necessary 
to consider introducing hierarchical multiplexing capability in 
specific network transition scenarios. One method for enabling 
multiplexing hierarchy is by introducing dedicated boards in a few 
specific places in the network and tunneling these new services 
through the legacy containers (ODU1, ODU2, ODU3), thus postponing the 
need to upgrade every network element to [G709-2012] capabilities. 
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In such cases, one ODUJ connection can be nested into another ODUk 
(j<k) connection, which forms the LSP hierarchy in the ODU layer. 
The creation of the outer ODUk connection can be triggered via 
network planning or by the signaling of the inner ODUj connection. 
For the former case, the outer ODUk connection can be created in 
advance based on network planning. For the latter case, the multi- 
layer network signaling described in [RFC4206], [RFC6107], and 
[RFC6001] (including related modifications, if needed) is relevant to 
create the ODU connections with multiplexing hierarchy. In both 
cases, the outer ODUk connection is advertised as a Forwarding 
Adjacency (FA). 


5.2. Implications for GMPLS Signaling 


The signaling function and RSVP-TE extensions are described in 
[RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines 
signaling extensions to support control for the legacy G.709 Optical 
Transport Networks. 


As described in Section 3, [G709-2012] introduced some new features 
that include the ODUO, ODU2e, ODU4, and ODUflex containers. The 
mechanisms defined in [RFC4328] do not support such new OTN features, 
and protocol extensions will be necessary to allow them to be 
controlled by a GMPLS control plane. 


[RFC4328] defines the LSP Encoding Type, the Switching Type, and the 
Generalized Protocol Identifier (Generalized-PID) constituting the 
common part of the Generalized Label Request. The G.709 traffic 
parameters are also defined in [RFC4328]. In addition, the following 
signaling aspects not included in [RFC4328] should be considered: 


- Support for specifying new signal types and related traffic 
information 


The traffic parameters should be extended in a signaling message 
to support the new ODUj, including: 


—  ODUO 

-  ODU2e 

- ODU4 

-  ODUflex 


For the ODUflex signal type, the bit rate must be carried 
additionally in the traffic parameter to set up an ODUflex 


connection. 


For other ODU signal types, the bit rates and tolerances are fixed 
and can be deduced from the signal types. 
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Zhang, 


Support for LSP setup using different TS granularity 


The signaling protocol should be able to identify the TS 
granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25 
Gbps TS granularity) to be used for establishing a Hierarchical 
LSP that will be used to carry service LSP(s) requiring a specific 
TS granularity. 


Support for LSP setup of new ODUk/ODUflex containers with related 
mapping and multiplexing capabilities 


A new label format must be defined to carry the exact TS's 
allocation information related to the extended mapping and 
multiplexing hierarchy (for example, ODUO into ODU2 multiplexing 
(with 1.25 Gbps TS granularity)), in order to set up the ODU 
connection. 


Support for TPN allocation and negotiation 


TPN needs to be configured as part of the MSI information (see 
more information in Section 3.1.2.1). A signaling mechanism must 
be identified to carry TPN information if the control plane is 
used to configure MSI information. 


Support for ODU Virtual Concatenation (VCAT) and Link Capacity 
Adjustment Scheme (LCAS) 


GMPLS signaling should support the creation of Virtual 
Concatenation of an ODUk signal with k-1, 2, 3. The signaling 
should also support the control of dynamic capacity changing of a 
VCAT container using LCAS ([G7042]).  [RFC6344] has a clear 
description of VCAT and LCAS control in SONET/SDH and OTN. 


Support for Control of Hitless Adjustment of ODUflex (GFP) 
[G7044] has been created in ITU-T to specify hitless adjustment of 


ODUflex (GFP) (HAO) that is used to increase or decrease the 
bandwidth of an ODUflex (GFP) that is transported in an OTN. 


The procedure of ODUflex (GFP) adjustment requires the 
participation of every node along the path. Therefore, it is 
recommended to use control-plane signaling to initiate the 
adjustment procedure in order to avoid manual configuration at 
each node along the path. 
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From the perspective of the control plane, control of ODUflex 
resizing is similar to control of bandwidth increasing and 
decreasing as described in [RFC3209]. Therefore, the Shared 
Explicit (SE) style can be used for control of HAO. 


All the extensions above should consider the extensibility to match 
future evolvement of OTN. 


5.3. Implications for GMPLS Routing 


The path computation process needs to select a suitable route for an 
ODUj connection request. In order to perform the path computation, 
it needs to evaluate the available bandwidth on each candidate link. 
The routing protocol should be extended to convey sufficient 
information to represent ODU Traffic Engineering (TE) topology. 


The Interface Switching Capability Descriptors defined in [RFC4202] 
present a new constraint for LSP path computation. [RFC4203] defines 
the Switching Capability, related Maximum LSP Bandwidth, and 
Switching Capability specific information. When the Switching 
Capability field is TDM, the Switching Capability specific 
information field includes Minimum LSP Bandwidth, an indication 
whether the interface supports Standard or Arbitrary SONET/SDH, and 
padding. Hence, a new Switching Capability value needs to be defined 
for [G709-2012] ODU switching in order to allow the definition of a 
new Switching Capability specific information field. The following 
requirements should be considered: 


- Support for carrying the link multiplexing capability 


As discussed in Section 3.1.2, many different types of ODUj can be 
multiplexed into the same OTUk. For example, both ODUO and ODU1 
may be multiplexed into ODU2. An OTU link may support one or more 
types of ODUj signals. The routing protocol should be capable of 
carrying this multiplexing capability. 


- Support any ODU and ODUflex 


The bit rate (i.e., bandwidth) of each TS is dependent on the TS 
granularity and the signal type of the link. For example, the 
bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps, 
while the bandwidth of a 1.25 Gbps TS in an OTU3 is about 
1.254703729 Gbps. 


One LO ODU may need a different number of TSs when multiplexed 


into different HO ODUs. For example, for ODU2e, 9 TSs are needed 
when multiplexed into an ODU3, while only 8 TSs are needed when 
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Zhang, 


multiplexed into an ODU4. For ODUflex, the total number of TSs to 
be reserved in an HO ODU equals the maximum of [bandwidth of 
ODUflex / bandwidth of TS of the HO ODU]. 


Therefore, the routing protocol should be capable of carrying the 
necessary link bandwidth information for performing accurate route 
computation for any of the fixed rate ODUs as well as ODUflex. 


Support for differentiating between terminating and switching 
capability 


Due to internal constraints and/or limitations, the type of signal 
being advertised by an interface could be restricted to switched 
(i.e., forwarded to switching matrix without 
multiplexing/demultiplexing actions), restricted to terminated 
(demuxed), or both. The capability advertised by an interface 
needs further distinction in order to separate termination and 
Switching capabilities. 


Therefore, to allow the required flexibility, the routing protocol 
should clearly distinguish the terminating and switching 
capability. 


Support for Tributary Slot Granularity advertisement 


[G709-2012] defines two types of TSs, but each link can only 
support a single type at a given time. In order to perform a 
correct path computation (i.e., the LSP endpoints have matching 
Tributary Slot Granularity values) the Tributary Slot Granularity 
needs to be advertised. 


Support different priorities for resource reservation 


How many priority levels should be supported depends on the 
operator's policy. Therefore, the routing protocol should be 
capable of supporting up to 8 priority levels as defined in 
[RFC4202]. 


Support link bundling 


As described in [RFC4201], link bundling can improve routing 
scalability by reducing the number of TE links that have to be 
handled by the routing protocol. The routing protocol should be 
capable of supporting the bundling of multiple OTU links, at the 
same line rate and muxing hierarchy, between a pair of nodes that 
a TE link does. Note that link bundling is optional and is 
implementation dependent. 
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- Support for Control of Hitless Adjustment of ODUflex (GFP) 


The control plane should support hitless adjustment of ODUflex, so 
the routing protocol should be capable of differentiating whether 
or not an ODU link can support hitless adjustment of ODUflex (GFP) 
and how many resources can be used for resizing. This can be 
achieved by introducing a new signal type "ODUflex(GFP-F), 
resizable" that implies the support for hitless adjustment of 
ODUflex (GFP) by that link. 


As mentioned in Section 5.1, one method of enabling multiplexing 
hierarchy is via usage of dedicated boards to allow tunneling of new 
services through legacy ODU1, ODU2, and ODU3 containers. Such 
dedicated boards may have some constraints with respect to switching 
matrix access; detection and representation of such constraints is 
for further study. 


5.4. Implications for Link Management Protocol 


As discussed in Section 5.3, path computation needs to know the 
interface switching capability of links. The switching capability of 
two ends of the link may be different, so the link capability of two 
ends should be correlated. 


LMP [RFC4204] provides a control-plane protocol for exchanging and 
correlating link capabilities. 


Note that LO ODU type information can be, in principle, discovered by 
routing. Since in certain cases, routing is not present (e.g., in 
the case of a User-Network Interface (UNI)), we need to extend link 
management protocol capabilities to cover this aspect. If routing is 
present, discovery via LMP could also be optional. 


- Correlating the granularity of the TS 


As discussed in Section 3.1.2, the two ends of a link may support 


different TS granularity. In order to allow interconnection, the 
node with 1.25 Gbps granularity should fall back to 2.5 Gbps 
granularity. 


Therefore, it is necessary for the two ends of a link to correlate 
the granularity of the TS. This ensures the correct use of the TE 
link. 
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- Correlating the supported LO ODU signal types and multiplexing 
hierarchy capability 


Many new ODU signal types have been introduced in [G709-2012], 
such as ODUO, ODU4, ODU2e, and ODUflex. It is possible that 
equipment does not support all the LO ODU signal types introduced 
by new standards or documents. Furthermore, since multiplexing 
hierarchy may not be supported by the legacy OTNs, it is possible 
that only one end of an ODU link can support multiplexing 
hierarchy capability or that the two ends of the link support 
different multiplexing hierarchy capabilities (e.g., one end of 
the link supports ODUO into ODU1 into ODU3 multiplexing while the 
other end supports ODUO into ODU2 into ODU3 multiplexing). 


For control and management consideration, it is necessary for the 
two ends of an HO ODU link to correlate the types of LO ODU that 

can be supported and the multiplexing hierarchy capabilities that 
can be provided by the other end. 


5.5. Implications for Control-Plane Backward Compatibility 


With the introduction of [G709-2012], there may be OTN composed of a 
mixture of nodes, some of which support the legacy OTN and run the 
control-plane protocols defined in [RFC4328], while others support 
[G709-2012] and the new OTN control plane characterized in this 
document. Note that a third case, for the sake of completeness, 
consists of nodes supporting the legacy OTN referenced by [RFC4328] 
with a new OTN control plane, but such nodes can be considered new 
nodes with limited capabilities. 


This section discusses the compatibility of nodes implementing the 
control-plane procedures defined in [RFC4328] in support of the 
legacy OTN and the control-plane procedures defined to support 
[G709-2012] as outlined by this document. 


Compatibility needs to be considered only when controlling an ODU1, 
ODU2, or ODU3 connection because the legacy OTN only supports these 
three ODU signal types. In such cases, there are several possible 
options, including: 


- A node supporting [G709-2012] could support only the control-plane 
procedures related to [G709-2012], in which case both types of 
nodes would be unable to jointly control an LSP for an ODU type 
that both nodes support in the data plane. 


- A node supporting [G709-2012] could support both the control plane 
related to [G709-2012] and the control plane defined in [RFC4328]. 
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o Such a node could identify which set of procedures to follow 
when initiating an LSP based on the Switching Capability value 
advertised in routing. 


o Such a node could follow the set of procedures based on the 
Switching Type received in signaling messages from an upstream 
node. 


o Such a node, when processing a transit LSP, could select which 
Signaling procedures to follow based on the Switching 
Capability value advertised in routing by the next-hop node. 


5.6. Implications for Path Computation Elements 


[RFC7025] describes the requirements for GMPLS applications of PCE in 
order to establish GMPLS LSP. PCE needs to consider the GMPLS TE 
attributes appropriately once a Path Computation Client (PCC) or 
another PCE requests a path computation. The TE attributes that can 
be contained in the path calculation request message from the PCC or 
the PCE defined in [RFC5440] include switching capability, encoding 
type, signal type, etc. 


As described in Section 5.2, new signal types and new signals with 
variable bandwidth information need to be carried in the extended 
signaling message of path setup. For the same consideration, the PCE 
Communication Protocol (PCECP) also has a desire to be extended to 
carry the new signal type and related variable bandwidth information 
when a PCC requests a path computation. 


5.7. Implications for Management of GMPLS Networks 
From the management perspective, the management function should be 


capable of managing not only the legacy OTN referenced by [RFC4328], 
but also new management functions introduced by the new features as 


Specified in [G709-2012] (for more information, see Sections 3 and 
4). OTN Operations, Administration, and Maintenance (OAM) 
configuration could be done through either Network Management Systems 
(NMS) or the GMPLS control plane as defined in [TDM-OAM]. For 
further details on management aspects for GMPLS networks, refer to 
[RFC3945]. 


In case PCE is used to perform path computation in OTN, the PCE 
manageability should be considered (for more information, see 
Section 8 of [RFC5440]). 
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6. 


Data-Plane Backward Compatibility Considerations 


If MI AUTOpayloadtype is activated (see [G798]), a node supporting 
1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps 
TS by combining specific TSs together in the data plane. The control 
plane must support this TS combination. 


Path 
4R---------- Ro —----------- > 4+---------- + 
| TS1==| eae ease +--TS1 | 
| TS2== | =========\--\------- +--TS2 | 
| TS3--|-------N--N--N------*--T83 | 
| TS4==|=====\--\--\--\-----+--TS4 | 
| | \ A A Vo4--185 | 
| | NON M +--TS6 | 
RES cir +--TS7 
\SrsSeRass> +--TS8 
4+---------- + <------------ 4+---------- + 
node A Resv node B 


Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TS 


Take Figure 5 as an example. Assume that there is an ODU2 link 
between node A and B, where node A only supports the 2.5 Gbps TS 
while node B supports the 1.25 Gbps TS. In this case, the TS#i and 
TS#i+4 (where i«-4) of node B are combined together. When creating 
an ODU1 service in this ODU2 link, node B reserves the TS#i and 
TS#i+4 with the granularity of 1.25 Gbps. But in the label sent from 
B to A, it is indicated that the TS#i with the granularity of 2.5 
Gbps is reserved. 


In the opposite direction, when receiving a label from node A 
indicating that the TS#i with the granularity of 2.5 Gbps is 
reserved, node B will reserve the TS#i and TS#it+4 with the 
granularity of 1.25 Gbps in its data plane. 


Security Considerations 


The use of control-plane protocols for signaling, routing, and path 
computation opens an OTN to security threats through attacks on those 
protocols. However, this is not greater than the risks presented by 
the existing OTN control plane as defined by [RFC4203] and [RFC4328]. 
Meanwhile, the Data Communication Network (DCN) for OTN GMPLS 
control-plane protocols is likely to be in the in-fiber overhead, 
which, together with access lists at the network edges, provides a 
significant security feature. For further details of specific 
Security measures, refer to the documents that define the protocols 
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([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]). 
[RFC5920] provides an overview of security vulnerabilities and 


protection mechanisms for the GMPLS control plane. 
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